       ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                   October, 1988  *
         *        *                                                  *
        *         *                              Volume 3, Number 4  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * **       *            ____  __.---""---.__  ____            *
                  *           /####\/              \/####\           *
           *      *          (/~~~~~)              (~~~~~\)          *
           *      *           \__OO/                \OO__/           *
       ******     *         __/                          \__         *
           *      *      .-"    .                      .    "-.      *
           *      *      ]  ]   \.._                _../   ]  ]      *
                  *       \  \    \."-.__________.-"./    /  /       *
       ********   *         \  \    "--.________.--"    /  /         *
             *    *       ___\  \_                    _/  /___       *
            *     *     ./    )))))                  (((((    \.     *
           *      *     \                                      /     *
            *      ******\           \_          _/           /******
             *     ********\    \____/""-.____.-""\____/    /********
       ********    **********\    \******************/    /**********
                  *           \.  .]                ].  ./           *
        ***       *         ." / ]  \              /  ] \  ".        *
       *   *      *      ."  /   ]   \            /   ]   \   ".     *
       *   *      *     /.-./.--.].--.\          /.--.].--.\.-.].    *
       *   *      *                                                  *
        ***       *                                                  *
                  *                                                  *
       ******     *                                                  *
           *      *                                                  *
           *      *                                                  *
           *      *                                                  *
       ****       ~~~~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~~~~
                  ~~~   ~~~~~~~  ~~ ~~~~~   ~~~~~~~  ~~~~~~~~  ~~~~ ~~
           *      ~~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~~ ~~~
           *      ~~~~~~~  ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~  ~ ~~~
       ******     ~ ~~~~ ~~   ~~~~~~~  ~~ ~~~~~   ~~~~~~~  ~~~~~ ~  ~~
           *      ~~~~~~~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~
           *      ~~~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~~~~~
                  ~~~   ~~~~~~~  ~~ ~~~~~   ~~~~~~~  ~~~~~~~~  ~~~~  ~
       ********   ~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~~ ~~~~
           *      ~~~~~~  ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~~~~~~~~~~  ~ ~~~~
           *      ~~~~~ ~~   ~~~~~~~  ~~ ~~~~~   ~~~~~~~  ~~~~~~~~  ~~
           *      ~~~~~~ ~~~~~~~  ~~~~~~~   ~~~~~~~~    ~~~~~ ~~~~ ~~~
       ****        ~~~~~~~~~~  ~~~~~ ~~~~~~~ ~~~~~~~ ~~~~~    ~~~~~ ~

1


             *     *              *     *                   *
             **    *         *    **   **       *       *   *
             * *   *  ***  *****  * * * *  ***  ****  ***** ****
             *  *  * *   *   *    *  *  * *   * *   *   *   *   *
             *   * * *****   *    *     * *   * *   *   *   *   *
             *    ** *       *    *     * *   * *   *   *   *   *
             *     *  ****   *    *     *  ***  *   *   *   *   *
        *****                                                    *****


       Christopher Condon    Editor                  CONDON @ YALEVM
       Timothy Stephen       Associate Editor       STEPHEN @ RPICICGE
       Craig White           Associate Editor        CWHITE @ UA1VM
       June Genis            Contributing Editor     GA.JRG @ STANFORD
       David Hibler          Contributing Editor   ENGL0333 @ UNLVM
       Henry Mensch          Contributing Editor      HENRY @ MITVMA
       Deba Patnaik          Contributing Editor       DEBA @ UMDC
       Gerry Santoro         Contributing Editor        GMS @ PSUVM
       Marc Shannon          Helpdesk Editor       HELPDESK @ DRYCAS
       Glen Overby           Technical Assistant   NU070156 @ NDSUVM1
       Gary Moss             Point of View             MOSS @ YALEVM


       ********************* Contents - Issue 26 *********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       The Human Factor ............................................ 3
       Flames To: .................................................. 7
       An Oprn Letter to Dr. James Conklin Jr. ..................... 9

       FEATURES_______________________________________________________

       BIOSCI Novw Available to BITNET/EARN ....................... 12
       Four Internet File Servers ................................. 14
       The Chaos Mailbox System ................................... 16

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 18
       Feedback ................................................... 19
       Policies ................................................... 23


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *


       -----------------------------------------
1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  CONDON@YALEVM
        *********


                            "One size fits all."


       One of the more frustrating experiences I have to go through is
       shopping  for clothing.    Somewhere  along  the line  my  body
       stopped growing  at a point where  no one keeps  my dress-shirt
       size in stock (15/32), my pants are hard to find (32/30) and my
       shoes are better suited to a duck (7 1/2 EEE).   Somehow all of
       these factors come  together to form a  relatively good-looking
       human being,   but finding  clothes for him  is an  exercise in
       head/wall pounding.

       Likewise,  finding the BITNET service  that fits your needs can
       be difficult.   Perhaps  the descriptions  of the mailing lists
       to which you subscribed were inadequate,  and they weren't what
       you were expecting.   Maybe the  file server you were accessing
       didn't organize its files in any particular way, and you had to
       wade though alphabetical listings.  It might have been that the
       Relay was not operational during the hours you needed it.

       As we have mentioned in the past, most servers and services are
       proviced by  volunteers.   As such,   it is often  difficult to
       criticize their  efforts without seeming ungrateful.    Not one
       wants to send  someone who has devoted many hours  of their own
       time  to making  BITNET better  a  note that  says,  in  effect
       "Compared to such-and-such,  your  server stinks."  (Substitute
       your own socially unacceptable adjectives where needed).

       People  either  stop  accessing  these  services  in  favor  of
       something else (often not on  BITNET)  or they continue because
       "it's all  there is."  Everyone  loses in this  scenario.   The
       users lose time and convenience they could and should have had.
       The  server people  lose valuable  input.    BITNET loses  some
       functionality.

       The key  to resolving  this problem  is to  provide a  means of
       feedback,  preferably  one which allows some  comparisons among
       different serverices in the same category.   For example,  what
       do people like about  CSNEWS as opposed to  COMSERVE (and vice-
1

                                                                Page 2


       versa)?   They provide  similar services to large  audiences in
       different ways.    Is there  some overlap  in their  user base?
       What features make one or the other easier to access?

       In distributing  the latest  BITNET USERHELP  I have  been very
       lucky in that  many people have sent me  mail listing comments,
       corrections, and so on.  While people seem to like the document
       a lot,   these changes  can make  the difference  between "very
       good" and "excellent".  The same is true for the servers.   You
       are the users, so you are the experts.  Tell the people who run
       these services what you think.  As  they say,  "the customer is
       always right".


                       Virtually,

                            Chris Condon@YALEVM
1

                                                                Page 3


        *********
       *         *  The Human Factor
       *         *
       *         *  by T. D. Stephen
       *         *
       *         *  Rensselaer Polytechnic Institute
       *         *
       *         *  STEPHEN@RPICICGE
        *********


       Believe it  or not,  there  are still people  in administrative
       positions  at computer  centers who  think that  undergraduates
       should be barred from the net.    I had assumed that this issue
       had breathed  its last,   that the  advocates of  this type  of
       discrimination  had finally  realized that  their position  was
       ill-considered --  in fact  contrary to  the best  interests of
       academic computing -- and had changed their minds.   Alas,  not
       so.   Ill-informed  about what actually  happens on  BITNET and
       wrong in their  assessment of the consequences  of student use,
       the advocates  of a student-free  network are still  out there,
       like kinks in a garden hose.

       The POLICY-L "list" jolted to  life recently when someone wrote
       to  inquire  about  arguments   that  might  persuade  computer
       administrators  at   Southern  Illinois  University   to  allow
       undergraduates to  use BITNET.   Well  known for  its excellent
       university press,   its leadership in  post-modern scholarship,
       and its beautiful campus near  the Shawnee national forest,  it
       would appear that SIU is also distinguishable as home to one of
       a small  number of computer  administrations that  continues to
       hold out  against an  expanded future  for computing  in higher
       education.

       The  keep-students-off-the-net  crowd  tend   to  defend  their
       position with three arguments: (a) a bureaucratic argument that
       claims  that student  access places  undue  strain on  computer
       center resources,  (b)   an economic argument that  claims that
       student access costs too much money,  and (c)  a moral argument
       that claims that student message traffic is frivolous and slows
       down "legitimate" message  traffic on the net.    I'd feel more
       hopeful if (c)  was the only  argument made.   If that were the
       case,  we could  lay the issue to rest by  simply assessing the
       uses to which  the net is actually put.   I  believe that after
       spending just  one afternoon pursuing  this,  two  things would
       become abundantly clear:  (1) that researchers, professors, and
       computer center staff engage in quite  a bit of "frivolous" use
       themselves; and (2) that distinctions between "educational" use
       and "social" use or between  use consistent with "research" and
       use for other purposes would  be virtually impossible to defend
1

                                                                Page 4


       or maintain.    Since no one  has yet  found the royal  road to
       knowledge,  it  is very difficult to  pass judgment on  what is
       educational  and  what  isn't.    All that  can  be  said  with
       certainty about  the variety  of ways  of knowing  and learning
       that  flourishes in  higher education  is  that protecting  and
       nurturing this variance probably ranks as one of the most noble
       goals that we in university life can aim for.   At any rate, it
       will take someone bolder than me  to say what is an educational
       use of the net and what isn't.

       But last December someone from Akron University reported on the
       UG-L list that administrators banished  their students from the
       net  after  discovering "...undergrads  obtaining  obscene  and
       porno  material through  BITNET...".    A  similar report  from
       Southwest  Missouri   State  noted   that  students   had  been
       "...discovered using BITNET relays for  social chatting,  and a
       small number of  students have been discovered  sending obscene
       messages and pictures." Assuming that  we are not talking about
       students  of anatomy,   human sexuality  or art,   it could  be
       difficult to extend a reasonable  definition of educational use
       to  include  exchanging  electronic pin-ups  or  messages  that
       describe sexual intercourse.

       Frankly,  however,   I really  don't know  why anyone  cares if
       consenting students (or faculty) exchange this sort of material
       or if they use BITNET to do it; every communication medium ever
       invented has carried sexually explicit  messages at one time or
       another and  all new ones  will too.    Those who would  try to
       eradicate communication about  sex may as well try  to halt the
       rain from falling or the trees  from losing their leaves in the
       fall; they have chosen to swim against one of life's most basic
       and powerful currents.   On the  other hand,  these reports are
       deeply  disturbing in  their  suggestion  that computer  center
       staff  have  felt  qualified  to   make  decisions  about  what
       constitutes pornography and obscenity;  and,  even worse,  have
       apparently not felt  timid or guilty about  violating the civil
       rights of their users by reading  their mail.   Imagine if your
       dean decided to  start eavesdropping on phone  calls or opening
       campus  mail.   Now  there's  a way  to  get  your school  some
       attention in the national press!

       The economic and bureaucratic  arguments against student access
       usually reduce  to fairly vague  suggestions about  student use
       leading to increased mainframe costs or student access tying up
       resources and thus interfering with the ability of the computer
       services unit  to fulfill  its mission on  campus.   I'm  not a
       computer  center administrator  so perhaps  I'm thinking  about
       this incorrectly;  however,  I assume  that an idling mainframe
       costs the university the same to operate as a mainframe that is
       used to capacity.  In other words, the mainframe, just like the
1

                                                                Page 5


       university's BITNET connection, is a static expense.   It seems
       to me, therefore,  that its sensible to look at BITNET as being
       a little like  an all-you-can-eat restaurant:  the  more of its
       resources the university can make use of, the better its value.
       Use of printers, tape drives, and disk packs is another matter,
       but one that is essentially irrelevant to the question of costs
       associated with using BITNET.

       I wonder if one of the roots  to the problem might be that some
       computing centers are  funded under a model  that actually *is*
       more  appropriate  for  a  restaurant  than  for  a  university
       information center.    If schools treat computing  resources as
       though they are consumable goods, people may be tempted to view
       each use of the computer as though it represented a dollar loss
       to the institution -- in the same way that a hamburger consumed
       at  a dining  hall  represents a  real  expense.   If  computer
       administrators take this model too seriously,  they may come to
       view BITNET access as a potential drain on their pool of finite
       resources.

       Imagine if the  campus library was run on the  same model:  the
       more books checked out,  the greater  the drain on the library.
       Charges would be  higher for checking out hefty  tomes like War
       and  Peace than  for checking  out shorter  works.   Those  who
       checked out many books would be expected to get a grant to fund
       their reading.   Ridiculous,  of course,   but only because the
       university  library  has  come  to be  viewed  as  an  integral
       component  in the  educational  process.    The more  books  in
       circulation --  in fact,   the more volumes  that there  are to
       circulate  --  the greater  the  mark  of distinction  for  the
       library and for the university as a whole,  and the greater the
       value of the  university library within the  academic community
       it serves.

       So  why aren't  computing  centers run  on  the  same model  as
       libraries?   One reason,  I suspect,   is that external funding
       agencies (e.g.,  the  National Science Foundation or  the Dept.
       of  Defense)  permit  universities  to  charge real  money  for
       computer time used toward fulfillment  of grants and contracts.
       To take  advantage of this,   computing centers have  needed to
       develop accounting systems.   The centers need to have a way to
       show not only what everything costs, but also *that* everything
       costs.   Under normal circumstances, however,  funding agencies
       do not allow  charges for time researchers  spend using library
       materials.   Thus,  there has never  been an incentive to think
       about running libraries on a for-charge basis.

       But it is important to consider that other point of distinction
       between libraries  and computer  centers --  the nature  of the
       mission that they perform on campus.   The library functions as
1

                                                                Page 6


       an integral  component in educational  practice but  the campus
       computer  center tends  not to.    Certainly you  can't have  a
       computer science major without a computer facility,  but only a
       handful of other  departments would see the  computer center as
       vital  to their  undergraduate programs.    BITNET brings  good
       reason  for   this  to  change.     BITNET  offers   access  to
       educationally oriented network services  (e.g.,  Comserve)  and
       thus invites computing centers to assume an expanded role,  one
       that,  in time,   will substantially increase the  relevance of
       computing across the academic spectrum.

       The arguments against students using BITNET are best understood
       as an  expression of a deeper  anxiety.   The real  concern,  I
       suspect,  is not  over how student message  traffic will affect
       the ability  of the net to  carry "legitimate" messages  or the
       amount  of computer  "funny-money" that  gets  consumed when  a
       student sends an electronic note over the net.   It is not even
       over the degree to which students  are responsible in their use
       of the  network.   The real concern  is the future  of academic
       computing itself.    BITNET membership invites  computer center
       administrators and staff to move  from their relatively limited
       (but  clearly  defined)   role  in  providing  researchers  and
       administrators with  numerical and  textual tools,   to a  more
       ambitious though   unfamiliar  role   in  facilitating   inter-
       university communication for the entire campus.  This move will
       propel  computer  services  organizations   to  a  center-stage
       position in educational programs across the disciplines.   This
       is a  major evolutionary step  and one  that may take  time for
       some administrators to come to terms with.

       Will campus computing centers universally accept the invitation
       BITNET  offers  to assume  an  expanded  role  in a  future  of
       networked  education?  Of  course they  will --  the issue  has
       already   been   decided.     Each  year   more   faculty   are
       enthusiastically exploring  ways of integrating student  use of
       the network into  their courses.   They are  experimenting with
       educational designs  that use BITNET  to connect  students with
       peers across  the country and  with faculty from  other schools
       and disciplines.   The time when computer center administrators
       will be  able to deny students  access to network  resources is
       quickly running out.   A few schools will hold out, but not for
       long.
1

                                                                Page 7


        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  University of Alabama
       *         *
       *         *  CWHITE@UA1VM
        *********

       Hello once again,

       I've been so busy  this month that I don't even  have a comment
       about how well my little corner of the net world was connected.
       I've received  too much  mail from  the lists  and have  seen a
       couple of mail-list faux pas.   I was very annoyed at one point
       by some  mail that  got loose  on a  couple of  the lists  that
       really made my in-box "look" full.  Maybe that problem has been
       fixed.    Even so,   I am  still excited  about networks,   and
       continue to find  new reason to become even more  so.   This is
       another one of those months where  I really can't classify what
       I have to  say as a flame,   but I feel that  these issues need
       some of your brain bandwidth.

       I've been  writing this column for  some months now and  I feel
       that I should give you some  information about myself.   I work
       in User  Service at  the University  of Alabama  and have  been
       using BITNET ever since our node was connected in 1984.  I have
       been a network fanatic ever since.   I am continually trying to
       persuade  friends,  acquaintances,   and anyone  else who  will
       listen to take advantage of opportunities that mail systems and
       computer networks have to offer.  Occasionally people return to
       me with horror stories of one type or another.   This month was
       one of those months.

       I have mentioned  the Rand book entitled "Toward  an Ethics and
       Etiquette for Electronic  Mail" which was written  by Norman Z.
       Shapiro and Robert H.  Anderson.   As  you might know,  I think
       that everyone who uses electronic  mail,  whether on a computer
       network,  a host based mail system  or even PC bulletin boards,
       should read  this book.    It discusses  many of  the potential
       problem  areas   involved  when   people  choose   to  exchange
       electronic  mail instead  of using  more  traditional forms  of
       comunication.   I do not keep copies of this publication around
       to give to  these people;  rather,  I tell them  where they can
       find it and  send them on their way.   Many  times,  maybe even
       most of the time,  no one takes the time to find a copy of this
       book and read it.  (By the way it's more like a booklet and you
       should be able to  read it in about the same  amount of time it
       would take to read a news magazine from cover to cover.)   Most
1

                                                                Page 8


       of  the horror  stories I  hear are  covered in  this book  and
       although it's not quite on the level of Stephen King,  I really
       think that all of you should make  the trek to your library and
       get this book.   I would like to  give those of you who haven't
       read the book a taste of what exciting topics are covered.  The
       following is  based on a true  story (only the names  have been
       changed to protect the innocent).

       This one is  from a friend of  mine,  we'll call him  Fred,  in
       corporate America  who's company  decided that  electronic mail
       was the  way to  increase productivity.    Their reasoning  was
       sound:  there  would be no  line to  report to the  boss,  they
       wouldn't  have to  play telephone  tag  with co-workers,   etc.
       Things were  going great  until Fred  was told  by a  friend in
       another department of a situation  that might have some bearing
       on Fred's  department.   It  seems that Paul,   who works  in a
       different group within Freds department,   had done a less than
       bang-up job  on an job  outside the department.    Fred decided
       that since this related to his  department it should be relayed
       to Ms.  Bigg, the departmental boss,  so she  would be informed
       in case anything was ever said.  He quickly prepared a piece of
       electronic mail and sent off to  Ms.  Bigg.   As it turned out,
       Ms.  Bigg, who had also been using electronic mail, knew how to
       forward a piece.    Can you imagine what  happened?   Ms.  Bigg
       forwarded the note  to a manager that was  over several groups.
       That  manager forwarded  it  to  Paul's manager,   who  finally
       forwarded the note to Paul, UNCHANGED.

       I am of the opinion that you should not send a piece of mail if
       it would bother  you if it ended  up typeset on the  front page
       the newpaper.   My freind in this  case wishes there  ware such
       things  as a  mail tag  that  says "this  is for  informational
       purposes only, no action required".

       Electronic mail can be be both a blessing and also a royal pain
       as evidenced by my friends horror story.   Nevertheless, I feel
       that  we  should continue  to  try  and  make  as much  use  of
       electronic mail as  is possible,  bearing in  mind the possible
       pitfalls.    As always  flames,   comments  and suggestions  to
       CWHITE@UA1VM.
1

                                                                Page 9


        *********
       *         *  An Open Letter to Dr. James Conklin Jr.
       *         *
       *         *  by Eric Keller
       *         *
       *         *  Universite du Quebec a Montreal
       *         *
       *         *  FONETIKS@UQAM
        *********


       * Editor's note:   Dr.  Conklin  was recently named Director of
       the BITNET Network Information Center.

       Dear Dr. Conklin,

       I have recently learned via NetMonth  that you are the incoming
       director of the BITNET Network Information Center. I would like
       to take this opportunity to communicate  to you some concerns I
       have concerning BITNET's operation,  concerns that I think need
       to be addressed as BITNET and its associated networks move into
       a  mature  phase of  serving  a  wide  variety  of needs  of  a
       worldwide academic community.

       I have networked seriously for close to two years. Since March,
       I have  been the editor of  foNETiks,  a monthly  news magazine
       serving  members  of  the  phonetic  sciences  community.   Our
       magazine  typically runs  from  30 to  40  pages and  presently
       reaches some 200 email addresses worldwide. As a result, I am a
       fairly heavy  user of BITNET.   While reader  satisfaction with
       this rapid means of scientific dissemination runs high, I think
       some operational concerns  need to be addressed  at BITNET over
       the next few years.

       My main concern  is the occasionally haphazard  manner in which
       mail  gets delivered.   Often,  mail  bunches up  for days  and
       suddenly arrives in gobs.  It is certainly strange to be logged
       on in  Quebec and to  receive a message  from a BITNET  site in
       Indiana  saying that  the mail  sent out  a week  ago was  just
       delivered.  According to reports in  recent issues of NetMonth,
       mail  sometimes  even  gets deleted  when  mainframe  usage  is
       particularly high.  With some nodes, a regular exchange of mail
       has turned  out to be impossible  because of the delays  or the
       uncertainty that the link entails.

       I  consider that  a VERY  HIGH  LEVEL OF  ASSURANCE ABOUT  MAIL
       REACHING ITS DESTINATION WITHIN A REASONABLE DELAY should be at
       the very top of BITNET objectives.  Network mail is no longer a
       luxury or a lark.  It comes close to being an essential service
       within the academic community,  and  thus needs to be supported
1

                                                               Page 10


       with  the  requisite  amount of  technical  and  administrative
       seriousness.

       No doubt  the BITNET  technical staff  will be  better equipped
       than I  to make  suggestions as to  how improvements  should be
       implemented.  But at least from this perspective,  I think that
       more intelligent routing programs are  called for,  in order to
       be  able to  automatically circumvent  nodes that  are down  or
       overloaded. Also, some automatic feedback program should be set
       up to oversee the operation of the whole network,  to report on
       nodes that are down,  and to "wake up" support personnel in the
       affected nodes. Although the lack of strong centralized control
       is  a hallowed  tradition  of  BITNET,  some  supervision  *is*
       required.  It is important to  have a mechanism  for soliciting
       the  cooperation  of nodes  that  are  not pulling  the  weight
       they've contracted to pull.

       Another concern is the explicit or  implicit limit on long mail
       files.  Issues  of foNETiks often  run longer than  100k.  Some
       nodes will simply not accept mail this large, and all of BITNET
       actively discriminates against large  mail file transmission by
       priorizing  the transmission  of  shorter  files.  Our  present
       solution is to  segment the magazine into  15-page portions and
       to mail them  separately.  That may circumvent  the problem for
       now, but it does not address the central issue.

       The  point  is  that much  academic  discourse  and  scientific
       information quite  naturally runs to  more than 100k.   A small
       printed science news magazine (like Discover,  Psychology Today
       or  Physics   Today)   contains  between   700  and   2000k  of
       information.  I don't  see why foNETiks should  be artificially
       constrained  to 100k.   My  colleagues and  I  write papers  in
       international  collaboration   via  BITNET,    and  many   such
       collaborations generate files longer than 100k. Some of us send
       data files from one lab to another via BITNET,  and these files
       are seldom shorter than  100k if they are to be  useful at all.
       Yet  everywhere we  turn,   the  active discrimination  against
       larger mail files  slows us down,  and  sometimes even imperils
       the very transmission of our files.

       I have full comprehension for  the physical and economic limits
       that originally led to the establishment of the small-is-faster
       philosophy. But the reality is that BITNET is now evolving into
       a more  mature phase of  its existence  and thus needs  to plan
       ahead to a period where a much larger set of academic needs can
       be served.   One  of these needs is the  possibility of sending
       longer files more rapidly and with complete assurance that they
       do not get deleted along the way.
1

                                                               Page 11


       This  means  that  nodes  will  have  to  make  available  more
       substantial resources. More parallel links between nodes should
       be planned for and established. Letters such as this one should
       be  used   to  convince  computer   center  support   staff  in
       participating nodes  that scientific publications  and academic
       exchanges often run  much longer than the  traditional one-page
       letter.  Long files  have a natural place on  BITNET and should
       get more respectful treatment than they do at the present.

       Finally,  I think  that access to the other  networks should be
       simplified.   In the  March  1988 issue  of  NetMonth,  I  have
       commented on  some of  the difficulties  I have  encountered in
       this respect ("Comments  of a So-so Happy  Crossnet User",  pp.
       9-11 ).  Ultimately,  this will only be possible if some simple
       mail addressing convention is agreed upon by all networks. This
       will probably involve a high level of abstraction to permit all
       networks  to translate  the  addressing  convention into  their
       particular internal  code.  Again,  the BITNET  technical staff
       will  be  much   better  equipped  than  I   to  make  concrete
       suggestions.  What  I am  concerned with is  that the  need for
       better and more transparent  universal addressing be recognized
       and  be translated  into  the  necessary high  priorization  on
       BITNET's agenda for future improvements and investments.

       Before this letter turns into a file longer than 100k,  I would
       like  to send  you my  best wishes  for your  upcoming term  as
       director.  I hope that you will be able to share in some of the
       concerns I have voiced here,  and will  be able to do your part
       in bringing these to the attention of BITNET's regents.
1

                                                               Page 12


        *********
       *         *  BIOSCI Now Available to BITNET/EARN
       *         *
       *         *  by Niall O'Reilly
       *         *
       *         *  University College, Dublin
       *         *
       *         *  NOREILLY@IRLEARN
        *********


       The  Irish  National   EARN  node,   IRLEARN, has   joined  the
       international network of BIOSCI  nodes which provide electronic
       mail   distribution    and   bulletin   board    services   for
       biotechnologists.

       IRLEARN is the fourth such node to date,  joining others at the
       BIONET  National  Computer  Resource   for  Molecular  Biology,
       Mountain  View,  California  for subscribers  in the  Americas,
       Daresbury  for subscribers  in the  United  Kingdom (mainly  on
       JANET),   and the  Biomedical Centre,   University of  Uppsala,
       Sweden for subscribers in Scandinavia (mainly on NORDUNET).

       IRLEARN will be the primary  distribution point for BITNET/EARN
       users, and will also serve users of the Irish Academic Network,
       HEANET.

       BIOSCI services provided from IRLEARN will include:

       * Automatic  distribution to BIOSCI  subscribers at  all BIOSCI
       nodes of electronic  mail messages sent to a  BIOSCI address at
       IRLEARN;

       * Automatic  distribution to BIOSCI  subscribers at  IRLEARN of
       electronic mail messages sent to a  BIOSCI address at any other
       BIOSCI node;

       * A BIOSCI archive from which collections of recent BIOSCI mes-
       sages may be retrieved by network users;

       * BIOSCI  bulletin boards which  will give local  IRLEARN users
       access to the BIOSCI archive.

       It is expected  that the archive and bulletin  boards will hold
       the messages of the current month  and those of the immediately
       previous month.

       Several different BIOSCI addresses for  electronic mail will be
       available  at IRLEARN,   as at  the other  BIOSCI nodes.   Each
       address is intended for messages on a particular topic, and all
       current addresses are shown below.
1

                                                               Page 13


       Each  address also  has a  corresponding  distribution list  at
       IRLEARN,   automatically   managed  by  the   Revised  LISTSERV
       software.    This  software  allows  network  users  to  become
       subscribers to any of the distribution lists, and so to receive
       electronic mail messages sent to  the corresponding BIOSCI mail
       address at IRLEARN  or at any of the other  BIOSCI nodes.   You
       may,  of  course,  subscribe to  as many of  these distribution
       lists as you wish. To subscribe, send the command

            SUBSCRIBE listname your_full_name

       to LISTSERV@IRLEARN via mail or message.

       The BIOSCI listnames are:

       BIONEWS  - General announcements
       BIOMATRX - Applications of computers to biological databases
       BIOTECH  - Biotechnology Issues
       SOFT-CON - Information on molecular biology programs
       EMBL-DB  - Messages to and from the EMBL database staff
       BIOJOBS  - Job opportunities
       GENBANKB - Messages to and from the GenBank database staff
       GENE-EXP - Gene Expression
       GENE-ORG - Genomic Organization
       METHODS  - Requests for information and lab reagents
       MOL-EVOL - Molecular Evolotion
       ONCOGENE - Oncogenes
       SOFT-COM - Information on communications software
       SOFT-PC  - Information on PC-software for scientists
       PIR-BB   - Messages to and from the PIR database staff
       PLANT    - Plant Molecular Biology
       PROTEINS - Protien Analysis
       RESEARCH - Reseach News
       SCI-RES  - Information about funding agencies, etc.
       SWISSPRT - Messages to and from the SWISS-PROT database staff
       YEAST    - Yeast Genetics
1

                                                               Page 14


        *********
       *         *  Four Internet File Servers
       *         *
       *         *  by Deba Patnaik
       *         *
       *         *  University of Maryland
       *         *
       *         *  DEBA@UMDC
        *********


       Mail  based  servers  are  simple yet  elegant.   They  run  in
       background all  day long  and provide  access to  a large  col-
       lection of files,  whcih may contain reports,  source programs,
       binary executables and bulletins.  In this month I am reporting
       four  new Internet  servers which  may be  accessed by  sending
       electronic mail. They are:

       ARCHIVE-SERVER@TITAN.RICE.EDU  -  This Rice  University  server
       stores  sun-spots digests,   contributed and  software for  SUN
       workstations.

       ARCHIVE-SERVER@SUN.SOE.CLARKSON.EDU -  The CLarkson  University
       server offers contributed LaTex and Postscript files.

       ARCHIVE-SERVER@BCM.TMC.EDU  - The  server  stores NFS  (Network
       File System) bulletins, contributed software for NFS and UNISYS
       related files.  It is run by Baylor College of Medicine

       WRL-TECHREPORTS@DECWRL.DEC.COM - The server stores abstracts of
       technical reports and complete reports in postscript format. It
       also allows  you to add your  address to the  technical reports
       mailing list  and order  hardcopy reports.   It  is run  at the
       Digital Equipment Corpoaration Western Research Lab.

       These servers  use the  same software  and allow  you to  write
       three basic commands: HELP, INDEX, and SEND.  The fourth server
       allows three additional commands;  they  are:   ADD,  ORDER and
       STATUS. Each command must be the first word on a line of a mail
       message.   The server reads your  entire message before it does
       anything,   so you  can have  several different  commands in  a
       single message.  The  server treats the "Subject:"  header line
       just like  any other  line of  the message.    You can  use any
       combination of upper and lower case letters in the commands.

       The  files  are organized  into  a  series of  directories  and
       subdirectories.   Each directory  has an index,  and  each sub-
       directory  has an  index.   The top-level  index  gives you  an
       overview of what  is in the subdirectories,  and  the index for
       each  subdirectory tells  you  what is  in  it.  The  following
1

                                                               Page 15


       explainations of the commands are  extracted from the help file
       of the servers.

       HELP - The  command "help" or "send help" causes  the server to
       send you the help file explaining all the commands.

       INDEX - If your message contains a line where the first word is
       "index",  then the server will send  you the top-level index of
       the contents of the archive.  If  there are other words on that
       line that match  the name of subdirectories,   then the indexes
       for  those subdirectories  are sent  instead  of the  top-level
       index. For example:

            INDEX
            or
            INDEX PROGRAMS
            or
            INDEX RECIPES

       You can then  send another mail message to  the archive server,
       using a  SEND command (see  below)  to ask  it to send  you the
       files whose names you learned from that list.

       SEND - If your message contains a  line where the first word is
       "send", then the server will send you the item(s)  named on the
       rest of the line.  To name an item,  you give its directory and
       its name.

           SEND RECIPE AFRICAN-STEW
           or
           SEND PROGRAM RCKEEP

       Once you have named  a category,  you can put as  many names as
       you like on the rest of the  line;  they will all be taken from
       that category. For example:

           SEND RECIPE CHOC-SHIP-1 CHOC-CHIP-2 CHOC-CHIP-3

       The following  three commands are supported  by WRL-TECHREPORTS
       server:

       ADD -  If you are not on  the mailing list for DECWRL,  you can
       add your mailing address (USPS) by a sending add in the body of
       your message, followed by your mailing address.

       ORDER - Allows you to order a harcopy of a technical report.

       STATUS -  This command allows you  to check the status  of your
       order.
1

                                                               Page 16


        *********
       *         *  The Chaos Mailbox System
       *         *
       *         *  by Frank Simon
       *         *
       *         *  Universitaet Oldenburg
       *         *
       *         *  151133@DOLUNI1
        *********


       (Translated into English by Thomas Zielke, 113355@DOLUNI1)

       CHAMAS (the Chaos Mailbox System) is a bulletin board which has
       been running at Universitaet Oldenburg since April,  1988.   It
       supports  the GEONET-standard,   developed  previously for  the
       GEO1-Mailbox.

       Commands should be sent to  107633@DOLUNI1.   The first command
       you  send should  be HELPME,   which can  be sent  via mail  or
       message.   You  will then be  prompted to specify  the language
       (English, French, etc.)   which you will be sending commands to
       CHAMAS.    You can  then send  the command  CMD for  a list  of
       commands.

       After subscribing to CHAMAS with the command NICK  (a
       procedure that is only necessary when using CHAMAS for the very
       first time), one is given the level-3-user privilege class.  In
       the root menu, the following services are offered:

              PBBS       - Public Bulletin Board System
              OBBS       - Official Bulletin Board System
              INFO       - Infos on CHAMAS and its site Oldenburg
                           You can also find special information, i.e.
                           on data networks, in this section.
              GATES      - Gateway to CCC, MCS and CHAMAS-Users
              SUBNET     - nformation from/to Subnet News
              PD         - Public Domain Software Bank
              MANAGER    - User Manager with system-functions

       PBBS includes read/write-boards like CHAMAS or HACK.

       OBBS  includes   read-only-boards  like   CCC  or   MCS.   Only
       level-2-users have  permission to  contribute to  these boards,
       which,  however,  means  that they are responsible  for 'their'
       board.

       The  Manager includes  general  functions  like changing  one's
       nickname, asking for a list of users etc.
1

                                                               Page 17


       Subnet is a collection of  discussion and information groups in
       Berlin.   It is working mainly on  Eunet/UUCP by Netmbx.  It is
       like NEWS by  UNIDO (for UUCP too).   Subscribe to  one or more
       groups and you  will get the news whenever  the CHAMAS receives
       something about the groups.  These are:

            General      - All on the world
            CCC          - Chaos Computer Club
            Flame        - Politics and Cultur
            ST           - Atari ST
            UNIX         - Unix and Xenix
            DNET         - (dnet.and.sub.general) All on the world
            sources.UNIX - Sourcelistings for UNIX
            VMS          - Vax/VMS-Operating System
            sources.MISC - Sourcelistings for the Rest
            Amiga        - Commodore Amiga
            Nets         - Nets and Networking
            Maps         - UUCP-Map (one time in month)
            Jokes        - Oh...i think....jokes
            OS9          - OS9 Operating System
            Politik      - Politics
            IBM          - Big Blue
            Science      - Science of World
            Motor        - Cars and so on
            Games        - Games and Adventures

       Most news items are written in German.
1

                                                               Page 18


        *********
       *         *  Headlines
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  Send your Headlines to BITLIB@YALEVM
        *********


       * From  Turgut Kalfaoglu:   The  are now four  TRICKLE software
       distribution  servers  in Europe.    They  are  TRICKLE@TREARN,
       TRICKLE@DKTC11,  TRICKLE@BANUFS11,   TRICKLE@IMIPOLI Note  that
       PCSERVER@BANUFS11 is gone. They have converted to TRICKLE.

       * CSNEWS is dead.   Long live UMNEWS:   As of December 1,  1988
       CSNEWS  and   it's  associated  userids   (CSSERVE,   CSNEWSOP,
       CSBACKUP)  will be  renamed to UMNEWS (and  UMSERVE,  UMNEWSOP,
       UMBACKUP,  respectively).   Thanks to  Andrew Robinson for this
       update.

       * The Ozone List and Newsletter:  This list and newsletter were
       set up  by people  do discuss  concerns about  about the  Ozone
       layer.   To join the list and subscribe to the newsletter, send
       the following  command to LISTSERV@ICNUCEVM:    SUBSCRIBE OZONE
       Your_full_name.   Finally  archives for the list  are sometimes
       available from LISTSERV@ICNUCEVM and the index can be retrieved
       by sending  the command GET  OZONE FILELIST.   The  editors are
       more than happy to accept contrivutions to the newsletter.   At
       the  moment you  can  send any  material  to Terry  Sommerville
       .    The  material  sought  includes  letters,
       comments, book reviews,  lists of references that you think are
       good or informative,  and summaries of articles.   Ideas on how
       to solve problems are also very useful.
1

                                                               Page 19


        *********
       *         *  Feedback
       *         *
       *         *  A Letters Column
       *         *
       *         *  "I'm a little puzzled..."
       *         *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Murph Sewall 
       Subject:  Name Servers

       Even before I read June Genis's letter in September's NetMonth,
       my  reaction   to  WHOIS@ALBNYVM1  and   IDSERVER@PSUVM  (while
       recalling NAMESERV@DREW and BITSERVE@CUNYVM  -which I'm told is
       "being phased out")   was AARRGGHHH!     Proliferation of  non-
       standard  named  servers  with   similar,   but  not  identical
       functions and commands potentially creates as many difficulties
       as they solve.

       June really has it right,  without  a common protocol the noble
       objectives  behind  the  creation  of  these  servers  will  be
       frustrated.   Anyone who has subscribed to a list for more than
       a  few weeks  has noticed  that  large numbers  of people  have
       difficulty remembering  how to  use LISTSERV  even though  list
       servers have the same name and commands.

       Name  servers at  individual nodes  make some  sense.   If  I'm
       looking  for   the  userid  of   my  friend  Pete   at  Albany,
       WHOIS@ALBNYVM1 is the logical place to look.  However, when the
       need arises,  probably  months from now,  I'm going  to have to
       remember that  at Albany  it's WHOIS while  at Penn  State it's
       IDSERVE but at Drew it's NAMESERV.   Then,  it'll probably take
       two or  three tries  (and some network  bandwidth)  to  get the
       command syntax  matched to  whichever server  - the  problem is
       obvious.

       An example  of a problem  of a  different kind exists  when the
       need arises  to notify  users with similar  interests of  a new
       service.   When the MBA-L list was created,  I used NETNAMES to
       search NETSERV's  UDS (User Directory Service)   World-wide for
       the presences of BUSINESS in the DESCRiptor lists.  Even though
       UDS was relatively new and not widely known outside of computer
       centers,  I found about 30 entries.    At present,  there is no
       process that will query node oriented name servers net-wide for
       a similar list.
1

                                                               Page 20


       I'm a little puzzled by  the editorial comment following June's
       letter.  NETSERV's UDS sure looks like a central name server to
       me.  The NETNAMES EXEC provides straight-forward, user friendly
       access, which includes the option of requesting replies by mail
       (I recommend mail  for an all nations search;   finding all the
       links  to every  national  NETSERV up  at  one  time is  pretty
       unlikely - I received some replies as much as a week later).

       Before we'll  have any chance of  having current data  for most
       active net users  into the UDS or any other  central data base,
       we need to  do something about the attitude problem  at some (I
       hope not very many)  nodes.   Several  months ago,  I asked our
       bitrep to consider  putting the NETNAMES EXEC on  the same disk
       that holds our MAIL software.   The  problem seems to be a fear
       that local  users might discover that  it's there and  begin to
       use it (this is a site  that denies students accounts access to
       BITNET by  default and makes  exceptions to the  blanket policy
       difficult to obtain).  So far, no NETNAMES available mail users
       generally.

       I have made one useful discovery.   Apparently, LISTSERVs which
       support the /WHOIS function automatically add names that arrive
       with  any  SUBscribe command  to  the  /WHOIS list  (if  you're
       subscribed to NETMONTH,  chances are that LISTSERV@MARIST knows
       you).  In short,  if  a person is an active enough  net user to
       have subscribed to a list or  two,  a /WHOIS query to LISTSERVs
       in  the vicinity  of the  users node  is likely  to return  the
       userid.   There  does not  seem to be  any expiration  for this
       feature (I know that a query to LISTSERV@MARIST for UCONNVM ids
       will return a  number of ids that haven't been  valid for quite
       some time); perhaps that's correctable?


       * Editor's  note:  I have been  thinking about that  lately and
       came up  with something  like this:    Every time  someone adds
       himself to  a mailing list,   he is identifying  his interests.
       What if every list  had a keywords for what the  list is about,
       and each time someone adds himself to a list the LISTSERV sends
       a registration command  to a CENTRAL name server.    If the key
       (userid@node) already exists,  the keywords are appended to the
       entry.   The user would have the option of accessing this entry
       and changing it, etc.

       There could be  mirror images of the central  server around the
       network.    Each night  it  would send  out a  log  of all  the
       commands it  received to the other  servers in order  to update
       them.    Add  to  this  an  automatic  deletion  facility  like
       NAMESERV@DREW and you have a pretty neat setup.
1

                                                               Page 21


       I agree that NETSERV UDS looks like a central name server,  but
       so  few  people actually  register  themselves  in it  that  it
       doesn't serve that  purpose very well.   Perhaps  this LISTSERV
       modification could  send UDS ADD  commands to NETSERV,   so new
       servers wouldn't have to be set up.


       From:     Ben Chi 
       Subject:  User Directories

       June Genis,   in her  letter in  the September  issue,  focuses
       squarely,   I think,   on  the  principal stumbling  blocks  to
       implementing global user directory services.

       The first  problem is  that of completeness  and currency  of a
       centralized  server.    The  success of  a  centralized  server
       depends crucially on people  volunteering directory information
       to it.   All experience up to  now suggests that this mechanism
       is less than totally successful in yielding useful results.

       On the other hand,  many individual sites DO operate local name
       servers (by whatever name)  whose data derive from more-or-less
       "official" information (e.g., the personnel database)  and,  as
       such, are both complete and current.

       But just  as there  is no  way to  compel individuals  to enter
       themselves in a centralized directory  or to keep their entries
       current,  so is it impossible to compel sites to implement name
       servers.   It  seems,  then,   that the  only way  to make  any
       progress is to make the best of what's available and do it in a
       manner  that shapes  future  developments  with an  eye  toward
       manageability.  To this end, we should

       1.  Encourage the establishment of more local name servers.  In
       this connection,   we need  to agree on  a common  protocol and
       syntax  for   directory  searches  and  make   server  software
       available to sites that want it.

       Establish a  "directory server," namely  a server  machine that
       reports  on the  whereabouts  of name  servers.    (This is  an
       extension of Genis' point #1.)    This needs some thinking out.
       It may  be that  a hierarchy  of directory  servers is  what is
       required,   each level  of the  hierarchy dealing  with a  more
       highly  delimited group  of sites.    (The  hierarchy could  be
       geographically based, but wouldn't necessarily have to be.   An
       attractive alternative  might be to  adopt the  Internet domain
       hierarchy more or less unchanged.)

       3.   Recognizing that  there will always be gaps  in the server
       firmament,  continue to support a central or some regional name
1

                                                               Page 22


       servers  to accommodate  users whose  sites don't  or won't  or
       can't provide local servers.

       In summary,  then,  the scheme  involves a directory server (or
       hierarchy of directory servers)  which point the inquiring user
       to a relevant local name server with "official" name entries if
       one  exists,  or  to a  central  or regional  name server  with
       "volunteer" name entries otherwise.

       Having  said all  this,  what  next?   To  get on  with it,   I
       volunteer  to try  to  deal  with the  protocol/syntax  problem
       mentioned in (1)   above.   Let's start with  what exists.   If
       people  will   send  me   the  help   texts  for   the  various
       WHOIS/NAMESERV/etc.  servers  currently in  operation,  I  will
       summarize them and attempt to draft  a standard that will serve
       as a basis for further discussion.   Perhaps some others of you
       can undertake  to deal with other  parts of the  problem.   But
       most  of all,   let's keep  the discussion  going.   I  suggest
       USRDIR-L as the medium,  and will post this letter to that list
       as well.

       * Editor's  note:   A  lot of  this depends  on HOW  you expect
       people to access a name server.   The primary purpose, I think,
       is not  to help locate  the userid  of a specific  person,  but
       rather  locate  groups  of people  with  certain  expertise  or
       interests.   In  this respect,   local name  servers,  or  even
       directories of name servers, won't do the job.
1

                                                               Page 23


        *********
       *         *  NetMonth Policies
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  ...but were afraid to ask.
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the command:

            UNSUB NETMONTH

       Internet users may use these methods, but must address the mail
       to LISTSERV@MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       LISTSERV@CMUCCVMA.  For a list of  files,  send the  server the
       the command:

            INDEX NETMONTH

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.
1

                                                               Page 24


       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.

       * Printing this file:  VM  users can print  this file  by using
       the "( CC" option of  the PRINT command.   VAX/VMS users should
       RECEIVE NetMonth  with a  format of  FORTRAN.  This  will allow
       page-breaks to be accepted by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************
